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Description 



This invention relates to a programmable controlled, goal oriented electronic system for form creation and form 
completion according to the preamble of claim 1 . 

5 Forms to gather data are employed daily in almost every commercial activity, in schools, and in all levels of gov- 

emment activity. It is a rare occurrence that an individuals life is not frequently touched by many forms. In the past, 
forms have been prepared by many processes ranging from hand and typewriter printed forms to engraved and mass 
produced forms. Prior to the advent of pervasive computing facilities, forms were completed by hand or by a typewriter 
and were generally interpreted by an individual. Today, there are many software packages which are capable of creating 

10 very fine printed forms. The recent proliferation of "Desk top publishing' software and of laser and inkjet printers has 
brought creation of good printed forms within the reach of individuals with high end personal computers as well as 

businesses. . 
Today, many electronic forms are completed by Individuals using a keyboard and/or a mouse or other pointing 

device- the data thus gathered is possibly stored for later reference; and a report is printed for an immediate purpose, 
rs In prior art systems known to me, to the extent that forms provide prompting of fields to be completed, the fields are 

presented in sequence without regard for the data entered in the course of completing the form. If a form is extensive, 

there may be prompting for information which is not relevant in the context of the answers which have been entered. 

This is wasteful of operator time since unnecessary information is often requested. 

In the prior art. in order to avoid prompting for unnecessary information, a first limited form is often presented for 
20 completion; the entries on that form are evaluated by an individual; and a decision is nfiade to require completion of 

one or more additional forms. Since there is no automatic prompting for completion of additional fomns which are 

dictated by answers on the completed fomi, the operator is unduly burdened with the decision process; and operator 

time is wasted. . ,. . , i, » ^ 

Forms are often used to describe and organize a complex decision process or "business policy . As such, the fomi 

25 contains blanks for both the inputs and results of the decision process. However, the form itself it typically very poor 
at describing the decision process other than by including notes in the margins. For this reason, many forms are 
accompanied by an instruction sheet, or "policy manual", which the operator must read, interpret, and apply in the 
process of completing the form. This is wasteful of operator time, makes it harder to disseminate new decision proc- 
esses, and results in many fomis being completed incorrectly. This weakness of paper fomns is not effectively addressed 

30 by current form software packages. coco 
In "High Level Form Definition in Office Information Systems", The Computer Journal, Vol. 26, No. 1 , pages 52-59, 
N H Gehani proposed a high level form definition language. The form definition language proposed is modeled after 
a procedural programming language. In "FORMS DEFINITION METHODS". 5th Annual '"ternational Conference on 
Computers and Communications 1 986. pages 708-71 2 another form definition language is described by M. Butterworth. 

35 The form definition described is a procedural language in its use of subforms. However, both fonn definition languages 
are unintuitive, and therefore ill-suited for use by non-programmers. Fomi creation by means of such fomi definition 
languages need programmers, which are trained in procedural programming language, but is not suitable such as for 

"^''^TlTiwention. characterized in claim 1 , is based on the problem to provide a goal oriented electronic system for 
40 form creation, form completion and using form data files which define: 

(a) a graphical image of a goal oriented form for display on a monrtor; and (b) a graphical image of at least one decision 
tree comprised of branches and conclusions which are discretely associated with fields of the fomn and which define 
logical and/or mathematical operations which implement goal oriented prompting within a form and among forms of a 

45 °FurthSr.' in accordance with my invention, my system for generating fomi data files defines: (c) reading and writing 
links between fields of the form and a variety of data sources and destinations; and (d) other fomis which, with the 
subject form, comprise a related set or "stack" of forms. , , . . • 

Provision of such inventive goal oriented electronic system which includes a graphical image of at least one decision 
tree defining these operations and provision of tools for modifying the graphical image of at least one decision tree 
50 ensure, that also non-programmers can create and complete interactive forms easily and quickly. 

For purpose of clarification, a "goal oriented" electronic fomi is one in which the prompts for answers generally 
flow through the form from left to right; and from top to bottom of the form; and the ongoing pattern of prompting is 
conditioned on answers provided to the form or on data obtained from referenced sources. Advantageously, as the 
answers to the field prompts are entered, fields which need not be answered are skipped, and fields on the same or 
55 a linked form are prompted in the desired sequence. 

In the event that an individual completing a report, by choice, revisits a completed field and enters a new value in 
the field my form system automatically executes a prompting sequence consistent with that new value, and calculates 
new values for fields which are dependent on the value in the changed field. Advantageously, it is thus possible to try 
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various "what-if scenarios. Tliis feature of my system is termed truth maintenance" since only valid and necessary 
prompting is implemented; and all calculated results are consistent with the values in the completed fields of a form. 

In accordance with my invention, my system provides a set of intuitive "creation" tools which readily permit creation 
of the above referenced form files. In an illustrative embodiment of my invention, form creation is divided into four 
5 natural selectively reentrant activities: an initial specification of the fields of a form to be created; specification of the 
tree branches and conclusions to implement the intended logical and mathematical relations of the form; specification 
of reading and writing links to selected data files; and specification of relations between forms to define a stack of 
related interdependent forms. 

Advantageously, these activities can be performed in any desired order; and each activity can be reentered se- 
10 lectively to make additions and/or corrections in order to accommodate thoughts which occur in the course of form 
creation. 

Furthermore, at any point in the process of form file creation, it is possible to selectively display: the current form; 

any selected part or all of the related tree structure; links to data sources and destinations; and the contents of a stack 

and the order of the contents in the stack. 
15 In accordance with my invention, if during the course of creating a form, an expression assigned to a branch or 

conclusion references a form field which does not exist, my system automatically creates a new field which adopts the 

established name. Subsequently, a field may be placed on the fomn to hold that name; however, if no field is assigned 

on the form, my system automatically prompts for a value at the appropriate place during the completion of the form. 

The prompt for such a field presents a prompt window that requests selection of a value for the question that does not 
20 appear on the form; however, a value is required for that field since continued prompting In the form is dependent on 

the value selected. 

In accordance with my invention, if during the course of creating a fonn, links are requested to a data base which 
does not exist, my system automatically creates a new data base with fields, which adopt the established names and 
characteristics of the fields contained in the form system. 

25 In accordance with my invention, "help" Infornnation may be assigned to a field during form creation; and that help 

information is available to an operator during form completion. 

In accordance with my invention, I provide "run time" software for operator completion, but not alteration, of pre- 
viously created forms. My "run time" software permits an operator to selectively view the trees associated with a form 
being completed to provide an understanding of the logical and mathematical relations and processes embodied in 

30 the form. Advantageously, my graphical tree displays identify "active" and "inactive" tree branches In accordance with 
data gathered in the form prior to display of the tree. 

Advantageously, my form system automatically reformats horizontal segments of a graphical display of a tree that 
covers two or more horizontal segments and two or more vertical screens in order to minimize the number of vertical 
screen displays required to show the entire horizontal segment. 

35 Advantageously, my system may be used to both create and complete goal oriented forms to implement inquiries 

in any situation in which the relations and functions of the fields of a form can be described by a tree of branches and 
conclusions. 

Although my forms provide goal oriented prompting, an operator may choose to depart from the suggested order 
of form completion. In accordance with my invention I provide a "resume" functipn which may be manually selected to 
40 retum to goal oriented prompting for further answers required to complete a form. 

During completion of a form, a field may require selection of a value from a defined set of values. The list of values, 
from which a selection is to be made, may be created manually during form creation; or may be derived from tree 
statements which: (a) are attached to the field and create answers which correspond to the selections in the list; (b) 
rely upon selection of a value from the list to complete evaluation of an expression; or (c) are established by a link to 
45 a database which provides values contained therein. 

In the course of form creation, the display of fields which require selection of a value from a set of values, as a 
design choice, may be defined as "selection list" fields or "check box" fields. 

In the case of a "selection list" field, a dialog window with a list of values is presented for selection of a value when 
the corresponding field is prompted for an answer A selection is made by moving a cursor over the desired item and 
50 clicking the mouse or depressing the return key 

In the case of a "check box" field, each value of the list is displayed with a small box for placing a check mark. In 
accordance with my invention, my fomn system automatically generates a field object which contains a number of 
selection boxes equal to the number of possible selections. Advantageously, my system automatically arranges the 
display of the set of selection boxes to match the size and shape of the field on the fomn. If the allotted field space is 
55 too small to accommodate all of the check boxes and their name text, the field is automatically defaulted to a "selection 
list" field. 

In accordance with my invention, keyboard entries are checked against "field characteristics" which are assigned 
to a field during form creation, tf a keyboard entry for a field is not consistent with the assigned characteristic, the 
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entered value is rejected and an error message advises the operator of a problem. Such characteristics can be assigned 
to a field by standard "picture" specifications. Alternatively, requirements for the form of a field input can be established 
by local form rules which are implemented by decision trees attached to the field. As an option, upon the occurrence 
of an error in input format, the field in error can be cleared and the prompt returned to that field to continue form 

''^'^kl accordance with an aspect of my invention fields of a form may be designated as "protected" or "unprotected'' 
at the time a form is created. Values cannot be entered manually in a "protected" field since only the values calculated 
for the field are considered valid. Even though a value may be automatically calculated for an "unprotected field, a 
value may be entered into the field manually to handle exceptional conditions. Fields with this characteristic are termed 
10 -over ride" fields. Advantageously, in accordance with my invention, my system clearly marks or flags both the display 
and printing of fields which contain over ride values. 

Fig. 1 is a block diagram of a personal computer 

Fig. 2 is an overview ot software employed in the personal computer of Fig. 1 ; 
IS Fig. 3 is a general view of the major elements of my goal oriented form software; 

Fig 4 is a general view of a form image data file; 

Fig. 5 illustrates an opening window of my form system application program and the menu commands available; 

Fig: 6 illustrates a Form Toot window and the menu commands available; 

Fig. 7 illustrates a Tree Tool window and the menu commands available; 
20 Fig 8 illustrates a Stack Tool window and the menu commands available; 

Fig. 9 is the first form in a set of four forms for an application for life insurance example; 

Fig 10 is the four forms for an application for life insurance example; 

Fig 11 is the third form in a set of four forms for an application for life insurance example; 

Fig 1 2 is the fourth form in a set of four forms for an application for life insurance example; 
25 Fiq 1 3 illustrates a window with a "goal" life insurance application for completion or modification; 

Fig. 14 illustrates the display of a second form for prompting of values necessary for completion of a goal form. 

Fig 15 illustrates the highlighting of the selected path in a tree; 

Fig. 16 illustrates the indication that a value for afield on a fomn has been overridden by a user; 
Fig. 17 is the dialog box for attaching context sensitive help to a field; 
30 Fig. 18 illustrates the automatic arrangement ot check boxes in a vertical region; 

Fiq 1 9 Illustrates the automatic arrangement of check boxes in a horizontal region; 

Fig. 20 illustrates the automatic presentation of a selection list when insufficient space is provided in a region for 

check boxes; , ♦ ^ « 

Fig. 21 is a dialog box for automatically or non-automatically specifying values expected for a field, 

35 Fig. 22 is a dialog box for specifying field protection; 

Fig. 23 illustrates a stack tool window with a display of related forms; 

Fig. 24 is a display of a branch object in a tree; 

Fig 25 is a display of a conclusion object in a tree; 

Fig. 26 illustrates multiple branches and expressions for calculating results for each branch; 
40 Fig. 27 is a dialog box for specifying conditions and conclusions in a tree; 

Fig. 28 is a dialog box for pasting functions into an expression; 
Fig. 29 is a dialog box for pasting field names into an expression; 
Fig. 30 illustrates a larger perspective view of a tree shown in Fig. 31 . 
Fig. 31 illustrates a more detailed view of a portion ot the tree in Fig. 30. 

45 Fig. 32 illustrates a self-referencing tree; ^ x- ... • i ^of=.h=.c^^c^• 

Fiq 33 is a dialog box for establishing links between fields in the form system and fields in related database(s), 
Fig. 34 is a dialog box for selecting the option to create a new database file when there Is no established file. 
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DETAILED DESCRIPTION 

The illustrative embodiment of my invention is disclosed as an application program running under Microsoft WIN- 
DOWS™ qraphical environment program on an IBM compatible PC. . ' • k« 

Notwithstanding, disclosure of my invention in this particular environment, the principles of my invention can be 
implemented as a program which includes an integral interface facility; or in the context of 

Although the graphical images and protocols employed by my form system are generaHy J^^^^^^^J 
environment, my system includes menu features which are not present in or contemplated by Wl NDOWS. The general 
features, functions and protocol of WINDOWS are described later herein with the introduction of the opening window 
of Fig. 5. 
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Fig. 1 is a very general block diagram of an IBM compatible personal computer (PC) which supports the Microsoft 
WINDOWS graphical environment, and, in turn, WINDOWS supports my form system which is described herein. 

The central processing unit (CPU) 100 typically employs a processor pf the Intel™ family of microprocessors. The 
read only memory (ROM) 101 contains the basic Input output system code (BIOS) for addressing and controlling floppy 
s disk 103, hard disk 104 and printer 108. Random access memory (RAM) 102 is the working memory for CPU 100. In 
a typical WINDOWS installation, RAM of two megabytes or more is employed. 

Monitor 1 05 of Fig. 1 provides a visual display; keyboard (KB) 1 06 and mouse 1 07 provide for manual input to any 
process running on the PC. Printer 108 creates hard copy images of output of the PC; and modem 109 provides 
communication between the PC of Fig. 1 and other computers. 
10 In Fig. 1, hard disk 104 is illustrated as containing a body of program and data information 121. Included in this 

body of information is a disk operating system (DOS), the WINDOWS graphical environment system software; user 
application programs which operate underthe WINDOWS environment; user application programs which do not employ 
the WINDOWS environment facilities; and data files of all sorts. 

Fig. 2 illustrates, in a general way the Interaction and flow of information between the Illustrated software entities. 
IS Non-WINDOWS application programs 201 -1 through 201 -M are served by the CPU 100 operating under Microsoft 

Corporation MS DOS system 206. Programs and data flow between Non-WI NDOWS applications 201 -1 through 201 -M 
and MS DOS 206 via paths labeled e.g., 210, 211. Paths 210, 211 are symbolic paths and are not intended to represent 
physical paths. 

The MS DOS operating system 206 employs MS DOS software device drivers to control the disks 221 and printers 
20 222 through the facilities of ROM BIOS 209, MS DOS device drivers also control system communication with the display 
monitor, an RS232 port, a keyboard, a modem and a mouse. 

WINDOWS application programs 203-1 through 203-N are served by WINDOWS graphical environment software 
205. The windows software comprises: User, graphical device interface (GDI) and Kernel modules. Symbolic commu- 
nication paths 21 2 and 21 3 pass function calls to WINDOWS software 205 and responses to the respective WINDOWS 
25 application software. 

WINDOWS device drivers 208 are the counterpart of MS DOS device drivers 207 and serve the same functions. 

In Fig, 3, box 300 represents the major software modules of my form system. In accordance with my invention my 
form system comprises two modes of operation, namely lorm creation" and "run time" form completion. Form creation 
comprises four phases: 

30 

(1) Definition of: a form image for alt fonns of an application, names of fields of the form or forms, and field char- 
acteristics; 

(2) Definition ot the forms of a related set i.e., a "stack" of forms and the assigned order of the forms in the set. 
When a form set is opened for completion, the defined order establishes which fomri of a set is the initial "goal" 

35 form, and the order in which the other forms of the set are presented for completion; 

(3) Definition of decision tree structures comprising branches and conclusions which are assigned to the fields of 
the forms which comprise a related stack of fomas; and 

(4) Definition of reading and writing links between fields of a form and extrinsic data sources and destinations. 

40 The four tool modules, 301 through 304 serve in the implementation of phases 1 through 4 referenced above 

herein. Tool modules 301 through 304 are not available in my run time form completion mode of operation. 

Memory manager module 305 manages the assignment of memory space. This module performs common func- 
tions for the other modules relating to the allocation and deallocation of portions of memory to contain data structures. 
It does this by allocating large portions of memory from Windows and dividing these into smaller portions as needed 

45 by the other modules. The memory manager also maintains a list of names used for forms, fields, system functions, 
and links (called a symbol table) so that the portion of memory associated with these items can be located and refer- 
enced by its name. 

Form execution module 306 and tree execution module 307 serve in implementation of my goal oriented form 
completion mode of operation. These modules are also available for use in conjunction with tools* 301 through 304 
50 during form creation. 

Link manager module 308 implements reading and writing communication with the extrinsic data sources and 
destinations defined during form creation. 

File l-O subsystem module 309, among other functions, controls the transfer and the form of data as it is moved 
between the hard disk and the RAM main memory of the PC. 
55 WINDOWS Interface module 31 0 provides communication between my form system and the WINDOWS graphical 

environment software. 

Fig. 4 represents the major divisions of my "form image data file" which is generated during form creation and is 
maintained in disk memory. A detailed description of the "form image data file" of Fig. 4 is included herein as Appendix 
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A which appears immediately before the Claims. 

File l-O Subsystem module 309 transfers a form image data file between main memory and the hard disk for 
storage and retrieval in the course of creation and completion of the form defined by the file. The image file stored in 
main memory and the corresponding image file stored in a hard disk contain the same data; however, the file in main 
s memory is a binary representation of the image data, and the file in hard disk is an ASCI I representation of the numerical 
and text portions of the image data. File l-O Subsystem module 309 makes the conversions during transfer of an image 
file. 

At the time that a form image data file is transferred to main memory for editing or completion, my form system 
analyzes the data therein and constructs a symbol table, a set of memory structures which correspond to each record 
10 in the data file (forms, form objects, fields, tree objects, and links), and "linked lists" which represent dependencies 
between the various form system components. The symbol table is a list of all names used in the form and the memory 
location of the records of that list. 

The linked list is required to determine the proper order for goal oriented prompting through the collection of forms. 
The linked list represents the data dependencies which are inherent in the decision tree definitions contained within 
IS the data file. These dependencies must be comprehended by the tree execution module when performing calculations 
or when determining the next field value to prompt for. 

Three types of dependencies must be maintained for proper execution by the tree evaluation module: 

(1 ) The use of a field as a branch condition within a decision tree. The value of the field must be determined before 
20 a branch can be selected. 

(2) The use of a field within a formula that specifies the condition under which a branch should be taken. The value 
of the field must be determined before the condition can be evaluated. 

(3) The use of a field within a fonnula that specifies the conclusion value at a terminal branch of a decision tree. 
The value of the field must be detennined before the conclusion can be evaluated. 

25 

All three types of dependencies are constantly maintained in memory using linked lists and are updated as required 
when additions or modifications are made to decision trees via the tree tool module. 

Figs. 5 through 8 illustrate various window presentations and pull down menu commands which may be encoun- 
tered in the use of my form system. 
30 Fig. 5 is an opening window which is displayed prior to sielection of a form application. The menu items shown in 

the main body of Fig. 5 are displayed on a mutually exclusive basis when the corresponding menu items. File, Edit, 
etc. are selected. Since this is the first window described herein, the features which are derived directly from the 
l^icrosoft WINDOWS environment are provided as background to the later description of my form system. 

In the terms of WINDOWS, software, such as my form system software, is called an application program. The term 
35 application as used in WINDOWS must be distinguished from forms by which an individual makes an "application" e. 
g., for credit approval. With the WINDOWS definition of the term "application" in mind, the WINDOWS environment 
provides for two general types of windows, namely, "application" windows which contain currently running application 
software and "document" windows which appear with application software that can display two or more windows si- 
multaneously. 

40 Document windows share the application window's menu bar. Commands that affect an application window affect 

the document as well. Document windows have their own title bar unless their physical size is maximized to fill the 
screen. In the latter case the document window and the application window share a title bar. 

Fig. 5 illustrates the opening window of my form system application program. The small rectangle in the upper left 
comer of the window of Fig. 5 represents the window control menu box which is found on all windows of the WINDOWS 

45 environment. The pull down menu for the control menu box of Fig. 5 is shown under that heading in the working area 
of the window. The menu for the control menu box and the main menu items are shown for purposes of discussion 
only. These menus are displayed only after a main menu command has been selected. 

The control menu commands permit an individual to: size, move, maximize, minimize and close windows; and to 
switch to Wl NDOWS Task List from a keyboard or by use of a mouse. 

50 The horizontal area to the right of the control menu box in Fig. 5 is the title bar which designates an application 

program e.g., Form System as shown in Fig. 5; and the title of the current active files under the named application 
program. The down and up arrows on the right side of the title bar are employed respectively to decrease and increase 
the size of the window. 

The pull down menu commands for the opening window, as described below herein, are tailored to my form system. 
55 When a pull down menu is displayed, the commands which are then available for execution are presented in a bold 
black type style; and the commands which are not available for execution are displayed in a readable, but somewhat 
obscured print style. 

For purposes of complete understanding, all of the menu commands of Figures 5 through 8 are described in 
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Appendix B attached hereto. 
Modes of operation 

5 As indicated earlier herein, my form system has two modes of operation, namely, form creation and run time form 

completion. In the following discussion, a description of form creation follows a description of run time form completion. 
This order of presentation is adopted because the description of a previously created form provides valuable insights 
into my goal oriented forms, and to the decision trees, links and form stack relations embodied therein. 

10 Form Completion 

For purposes of illustration, a set of four forms for making application for life insurance are displayed in Figs. 9 
through 12. The data file containing the life Insurance forms is entitled Life.DF. 

When form completion proceeds during a 'run time" session of my form system, a subset of menu commands are 
^5 available to the user. For example, none of the Tools (Forms, Tree, Stack and Link) are available. 

In Fig. 5, an operator selects the "Open" command from the 'File" menu. In response to this command, my form 
system provides a list of fomn files, including Life.DF, which are available for selection. A selection is made by high- 
lighting the file to be selected and either clicking the mouse or striking the RETURN (or ENTER) key on the keyboard. 
Following selection of a form file e.g., Life.DF a screen essentially as shown in Fig. 1 3 is presented to an operator for 
20 completion. The form shown in the window of Fig. 13 is also shown in Fig. 9. 

When a goal form e.g., the Life Insurance Application form is presented as shown in Fig. 13, the first field to be 
completed, Proposed Insured is outlined in a heavy line and a large "I" shaped cursor is presented in that field. Infor- 
mation input to a prompted field may comprise: typed information followed by depression of the RETURN key of the 
keyboard; or may comprise selection by use of a mouse or by use of the ARROW and RETURN keys of the keyboard. 
25 In order to implement goal oriented prompting, my system first determines which form is the goal form. When an 

application is initially loaded into memory, the top form of the stack is selected as the goal form. Later, an operator can 
use the "Select" command on the "Form" menu to select another form to become the goal form. 

Once a goal form has been selected, my form system selects the first field without a value on that form as the goal 
field. It does this by searching down the linked list of field objects on the form until it finds a field that does not currently 
30 have a value. 

Once a goal field has been selected, my system next determines which field, if any, is dependent on the goal field. 
This is done by looking at any decision trees which are associated with the field to determine which field in the decision 
tree is next needed to complete the tree. This is done by starting at the base of the tree and following all selected 
branches of the tree until my system detects either a branch node that does not have a value, a condition expression 
35 that does not have a value, or a conclusion expression that does not have a value. This field, if any. becomes the 
dependent field which my fomn system must prompt for next. 

Once my system has determined which field to prompt for, the system next locates any form that contains this 
field. Starting at the top of the stack, my form system looks at each form in turn to find which form closest to the top of 
the stack contains that field. My form system then moves that form to the top of the stack so that the user can enter a 
40 value. If the field is not found on any form, my system prompts for the field on a special "scratchpad" form. 

Once the form containing the dependent field has been moved to the top of the stack, my system then positions 
the cursor on the dependent field and prompts the operator to enter a value for that field. 

in the Life Insurance Application example shown in Figures 9 through 12, my system automatically prompts for 
fields contained on the Premium Calculation, Declarations, and Medical Information forms, as necessary, to complete 
45 the Life Insurance application form. Fig. 14 shows the display after the Premium Calculation form has been automat- 
ically moved to the top of the stack to prompt for "Amount of basic policy". This was done because my system determined 
that "Amount of basic policy" was the next dependent field necessary to calculate a value for the "Total Annual Premium" 
field on the Life Insurance Application form, which was the goal form. Since the Premium Calculation form was moved 
to the top of the stack temporarily due to my goal oriented prompting, it is identified as as prompt form by displaying 
50 the word "prompt" after the title of the form as shown in Fig. 14. This form will also be automatically removed from the 
display once the operator enters values for the dependent fields on it. 

Rather than provide values for dependent fields, an operator can use the "Close" command on a prompt form's 
control menu to close the form at any time. When the operator does this, my system moves to the next field on the 
current goal form and proceeds with the goal oriented prompting for its dependent fields, if any. 
55 An operator can also cause my system to pursue goal oriented prompting for any field of his or her choice by first 

selecting the field, then using the "Calculate" command on the "Field" menu. This causes my system to make the 
selected field the goal field for purposes of goal oriented prompting. 

After a user has entered a value for a field, whether or not a prompted fild, my system must propagate that value 
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throughout any forms and decision trees associated with that field. I call this feature of my system "truth maintenance" 
because it maintains at all times the logical and/or mathematical relationships between fields on forms. The actual 
implementation of truth maintenance is based on the linked list structures that are created as a form image data file is 
transferred to main memory. The first step of this process is to remove the previous value, if any, of the field before 

5 the user typed a new entry. Once the previous value has been removed from the field, this change is propagated to 
any fields which are dependent upon that field to remove all prior dependent values. The second step is to place the 
newly entered value into the field; and to propagate the changes to all dependent fields. 

My system then looks and determines which forms, if any, contain the field and displays the new value on each of 
those forms. If the goal form, which the system selected in its goat oriented prompting, now has a value for the field 

10 which was originally the goal field, or if the operator did not enter a value for the prompted field but rather answered a 
value for a different field, or if the operator pressed the Tab Key, then the goal form is advanced to the next field and 
the goal oriented prompting sequence starts over again for that field. 

My form system also maintains any dependencies related to external sources of data that have been linked to the 
forms. When the value of a field that is used as an index for a database is modified, my system automatically locates 

15 the appropriate record and updates the values of any fields linked to the database. Similarly, when the value of a field 
that is exported to another application is modified, my system automatically notifies the other application of the change. 

In the Life Insurance Application example shown in Fig. 13, when the operator enters the applicant's name, my 
system automatically looks in a database file for information about the applicant. If infomnation about the applicant is 
found in the database file, the applicant's address, date of birth, etc. is retrieved from the file and the system automat- 
ic ically skips over these fields. If no information about the applicant is found in the database file, the system prompts the 
operator for this information. 

Upon entry of a value for any field, my system automatically prompts for entry into the next field according to the 
goal sequence defined above. As values are entered into the prompted fields, automatic prompting may continue on 
the initial goal form to completion of that form; or dependent on the values entered in certain fields, prompting may 

25 digress to a subsidiary fomn of the stack. In any event, form fields which receive their data from linked data sources or 
by calculation are not visited by the prompting cursor. 

If the cursor is manually moved to a field which receives data from a linked source or by calculation, the outline of 
the field is a distinctive dotted border to advise that the operator is not expected to provide an answer In the illustrative 
Life Insurance Application form of Fig. 13, the fields: "Proposed insured", "Beneficiary name". "Beneficiary address". 

30 etc. are all fields for which the operator is prompted for an answer On the other hand, the fields; "Total Annual premium", 
■Premium payment amount"; and "Deposit required" are fields which receive their values by calculations. 

Fig. 15 illustrates the ability of the system of my invention to highlight the selected path in a tree for the user In 
this case, the tree for "premium payment amount" is currently determined by the value first for the insured not meeting 
the basic requirements being "no" and the mode of payment being "monthly" with a thicker line for that selected path 

35 and then the calculation corresponding to monthly mode of payment is the expression which is used to calculate the 
prennium payment amount. 

Also of note in Fig. 15 is the use of different icons in the decision tree display to distinguish calculated fields. The 

leftmost branch object includes a decision tree icon above the branch field; in this case "Insured does not meet basic". 

This decision tree icon indicates that the value of "Insured does not meet basic" is calculated via a decision tree rather 
40 than being entered by the operator The other branch object, for "Mode of payment", does not have this icon. "Mode 

of payment" is a field which the operator must enter This display technique highlights the capability of my invention to 

embed arbitrarily complex computations which result in a value for a field within a single branch object. 

Finally, in Fig. 16 is the capability of my invention to indicate that a value for a field has been entered by the user 

overriding the value that would be brought to that field from the tree. In this example, the field called "Premium Payment 
45 Amount" has been entered as $1 50.00 by the operator and the cross/hatching over that field indicates that this value 

was entered by the operator rather than by the tree that is available for that correct determination of the premium 

payment amount. 

Form Creation 

50 

I contemplate that my form system will be widely used to create sets of forms for all types of commercial, industrial 
and other applications of my form system almost without limitation. 

Form creation in my invention involves the use of four interrelated tools. The fomn tool, the stack tool, the tree tool, 
and the link tool. These will be discussed individually in the following paragraphs. 

55 ■ 

Fonri Tool 

The form tool of my system is a facility for creating and modifying application forms. The fomn tool provides a high 
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level, graphical method for defining forms. It operates much tike a drawing package and displays forms as they are 
being defined. 

I view a form as a physical area which can be divided into a plurality of regions. The physical size of a region can 
be selectively set; and a region can have a border on any or all sides. The width of a region must be an integral multiple 
5 of the pitch of the default font employed in a form; and the height'of a region must be an integral multiple of the height 
of the default font. The borders for adjacent regions are shared. 

Form objects fall into two general classes, namely, static and dynamic. Regions which are assigned static form 
objects are not involved in my goal oriented prompting. The static form objects are: text, graphics, filled rectangles, 
rounded rectangles and lines. There is a single dynamic form object field. Each Field must have a name for Identification 
10 and reference in trees, conclusions, and links. 

There are three static form object regions in the illustrative insurance application of Fig. 13. The large title region 
with the text "Apex Life Insurance Company" and the signature region at the bottom of the form of Fig. 1 3 are both text 
form objects. The title region illustrates the use of text font type and size which are different from the default text. The 
region to the right of the region named "Premium payment amount" is a filled rectangle form object. 
15 The remaining regions of the form of Fig. 1 3 are field form objects which are for ease of reference termed "fields" 

herein. Fields are employed to display: (a) data entered by a user; (b) data calculated by my fomn system; or (c) data 
provided by a link to an external source. 

All form objects have assigned "properties" which define: size, appearance, and functions attributable to an object. 
For example, all form objects may be assigned a border property; and this Is the only property which can be assigned 
20 to filled rectangle or graphics objects. Font and alignment properties, also, can be assigned to text objects. 

In contrast to the limited number of properties available for .assignment to the "static" form objects, a wide range 
of properties can be assigned to "fields". The properties which are available for assignment to field are enumerated in 
Fig. 5 under the menu heading "property". A description of these properties is to be found in Appendix B hereof, under 
the heading Properties . 

25 Once a general plan for the forms of an application has been conceived, form creation begins with use of the Form 

Tool of my system. The operator invokes the Form tool by using the "Form" command on the "Tools" menu shown in 
Fig. 5. 

The fomn tool provides the following capabilities: (a) creation of a new form; (b) adding new objects to a form; (c) 
renaming, sizing and scrolling forms; (d) finding forms that contain a specified field; (e) selecting, moving and sizing 

30 form objects; (f) editing form objects with the clipboard; (g) changing the field referenced by a field object; (h) changing 
the names of field and text objects; (i) adding help text to be displayed for a field object; (j) changing the display format 
of a field object; (k) changing the alignment of text within field objects and text objects; (1 ) changing the character fonts 
of text objects and field objects; (m) controlling which, if any, borders are drawn around objects; (n) controlling whether 
the field name is displayed in a field object; and (o) protecting field objects both from override by the operator or display 

35 of the tree associated with the field object. 

The Life insurance Application referenced earlier herein, as an example, illustrates several features which are 
provided by my form tool. Fig. 17 shows the dialog box for attaching context sensitive help to a field using the "Help" 
command on the "Properties" menu in Fig. 6. In this example, the help for the field called "Proposed Insured" is an 
elaboration of some information that may be of value to the operator filling out the form. 

40 Fig. 18 and 1 9 illustrate an automatic feature provided in the form tool that places check boxes within the space 

allotted to a field. In Fig. 18 a vertical space is alloted a field called "Mode of Payment" and the check boxes are 
displayed accordingly. In Fig. 19 a horizontal field is provided for mode of payment and the check boxes are arranged 
accordingly. Fig. 20 shows the case where insufficient space is allocated for "mode of payment" and although check 
boxes are Indicated, the system automatically provides a selection list since there is insufficient room for the check 

45 boxes. There is always room for the selection list since even as the list grows, scroll bars can be added to the display 
and an arbitrarily long list can be shown. 

Fig. 21 shows a dialog box that allows for the automatic generation of the values for fields. This dialog box appears 
whenever the operator changes the type of a field to either "selection list" or "check box" using the " Field Type" command 
on the "Properties" menu shown in Fig. 6. The automatic determination of the values looks at values that can be 

50 attached from the tree, values that are used in a tree which employs the field for determination of the other tree's valu e, 
or finally automatic creation of the values by looking at the values that can be brought from the records of a database. 
If automatic is not selected, then the new values are manually entered in the edit box under "New Value" and then 
added to the list in the box called "Values". 

Another capability of my invention is to provide protection of fields contained on forms and there are two different 

55 protection modes possible. Fig. 22 shows the dialog box that can be used to disallow override values using the "Pro- 
tection" command on the "Properties" menu shown in Fig. 6. The meaning of no override is that the user is not allowed 
to override a value which has been assigned to the field from a tree or from a database reference. Field protection can 
also block the ability for the user of the application to observe the decision tree logic for a particular field. Both of these 
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protections are done on a field-by-field basis. 
Stack Tool 

5 The Stack Tool, which provides tor manipulation of the fonns of an application, is a high-level, graphical facility for 

copying, creating, deleting and arranging forms. Within the stacktool there are specific capabilities that allow application 
creators to create new forms, change the title of an existing form or change the order of the existing forms within an 
application. For instance, it is often useful to change the order of forms to move a new form to the top of the stack so 
that it becomes the goal form when the application is initially loaded into memory. 

TO The stack for the Life Insurance Application used in the previous description of form completion is depicted in Fig. 

23. Fig. 23 depicts a window which is displayed when the stack tool is chosen using the "Stack" command on the 
■Tools" menu. It shows the four related fomns that comprise the "stack" or set of forms for this application. As seen In 
Fig. 23, the stack for the file Life.DF comprises the goal form and three subsidiary related forms. Of special note in 
Fig. 23 is the fact that the top form of the stack, in this case the Life Insurance Application form, is depicted as a goat 

15 form through the use of a special Icon for the top-most form in the stack. 



Tree Tool 



In my invention, another specialized tool called the Tree Tool is provided in order to create and modify decision 
20 trees. The Tree Tool is invoked by the operator by first selecting the field associated with the tree and then using the 
"Tree" command on the "Tools" menu as shown in Fig. 5 and Fig. 6. 

Two basic types of objects can be created using the tree tool. The first object is the branch object which is shown 
in Fig. 24 highlighted with a broken line. The branch object consists of a condition of the preceding field; in this case, 
Field 1 . The first condition of Field 1 , condition 1 A, is the condition leading to the highlighted object. The second part 
25 of the branch object is the field upon which the new branch will be taken; in this case, Field 2. 

Fig. 25 illustrates the conclusion object. The conclusion object is highlighted with a broken line. The conclusion 
object consists of a condition that the preceding field, again in this case Field 1. The second condition of Field 1, 
condition IB, is the condition of this object. The second part of the conclusion object is the conclusion itself; in this 
case, just indicated with the word "Conclusion". Conclusions can be text, fields, functions, or combinations of the 
30 proceeding in expressions connected with operators using spreadsheet syntax. 

Fig. 26 shows multiple branches from an example field called "Mode of Payment". If mode of payment is "annual", 
the value for the premium payment amount is the "total annual premium" as indicated in the conclusion for that branch. 
If the payments are made "semi-annually", the expression uses the function ©ROUND of the total annual premium 
multiplied times the factor that it adjusts it for the fact that there are two payments made during the year (each equal 
35 to about one-half or 0.51 5 of the annual amount). The @ ROUND function also requires specification of the nunnber of 
decimal places. In this example, the value set at two places gives a dollar and cents amount. My system provides a 
complete set of built-in functions, such as ©ROUND, which can be used within tree conditions and conclusions to 
calculate values based on field values. These functions are listed in Appendix A under the heading "ID Function". 
A dialog box like that shown in Fig. 27 is displayed as a part of the specification of both conditions and conclusions. 
40 This dialog box appears when the operator selects either the "Condition" or "Conclusion" command on the "Properties" 
menu shown in Fig. 7. The condition or conclusion expression is contained within the edit window in the upper part of 
the box. There are options to assist the entry process by providing pasting of functions and fields into the condition. 
For the case of pasting functions, Fig. 28 shows a portion of the list of functions available in alphabetical order including 
an option to paste in descriptive arguments for the functions. Fig. 29 shows the dialog box allowing the pasting of fields. 
45 This is simply a listing of all of the fields currently defined in the application thereby saving a number of keystrokes for 
the choice of a field from the list of all possible fields available. 

My invention also provides a very innovative approach to the display of arbitrarily large trees in a fixed-size region, 
such as on a computer display. Figures 30 and 31 both display the same decision tree but at two different levels of 
magnification. Fig. 30 shows a larger view than that shown in Fig. 31 . In Fig. 31 the fields, the branches, the conclusions 
50 are arranged with spacing to maximize the amount of information displayed. If a more magnified view is selected, like 
that of Fig. 31 , the branches and conclusions are rearranged with closer spacing in order to fill in some of the blank 
space that would be available if the prior spatial arrangement of Fig. 30 were maintained. 

To maximize the display of tree objects on a fixed size display, my system first detemnines how many tree objects 
to display in one horizontal row of the display. The operator can control the number of tree objects displayed in a 
55 horizontal row by using the "Expand" command on the "View" menu to decrease the number of tree objects or the 
■Reduce" command on the "View" menu to increase the number of tree objects. 

Once the number of tree objects in a horizontal row is determined, my system next detemnines the number of tree 
objects that can be displayed in a vertical column while maintaining the proper aspect ratio of tree objects. My system 
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then displays one horizontal row ot tree objects at a time without displaying any objects that are beyond the rightmost 
edge of the display. Any horizontal rows which contain only tree objects beyond the rightmost edge of the display are 
not displayed. The result of eliminating these rows is that the display surface Is more densely packed with at least one 
tree object in each horizontal row. This eliminates much of the "white space" that would occur when displaying portions 

5 of a large tree near the root of the tree. 

Fig. 32 illustrates the use of a tree that has as one of its possible conclusions the value of the field for which the 
tree is being determined. The ability of a tree for a particular field to reference itself is useful in providing the user of 
the system with values determined by the tree it the tree has anticipated the values of interest. But in the case where 
the values have not been anticipated by the tree, the self-reference allows the field to be prompted so that the operator 

10 can enter the information directly. 

Links Tool 

In my invention, the Links Tool provides an ability to relate the fields on the form system with the fields in related 
IS database(s). Fig. 33 shows the dialog box for establishing both read and write links between applications and the 
databases. The Links Tool dialog can be entered from either form completion mode or from the Form Tool by using 
the "Links" command on the "Tools" menu. 

The Links Tool dialog shown in Fig. 33 allows the operator to associate database fields (listed on the left side of 
the dialog box) with fields defined within my form system. This association can be made for both the purpose of reading 
20 data from the database and writing data into the database. Fig. 33 is from the Life Insurance Application example used 
earlier and shows how an applicant's address, city, state, etc. can be obtained from a database given the applicant's 
name. 

Fig. 34 shows the ability of my invention to take care of a case where there is not an established database in place 
corresponding to the values of the fields within my forms system. In the illustration of Fig. 34, a link named "New Link" 
25 has been attempted with a database; in this case, a database table named "New File". The system was unable to open 
that file because that file did not exist and the option provided in the dialog box allows the operator to create a new 
database table with this name. My system uses the properties of the fields as defined by the operator to create database 
fields of the appropriate size and type. 

My invention has been described with particular attention to its preferred embodiment; however, it should be un- 
30 derstood that variations and modifications within the spirit and scope of the invention may occur to those skilled in the 
art to which the invention pertains. 

APPENDIX A 

35 The following is the file format in which my graphical image data file for documents are saved on disk. 

The file is a binary file and can be considered to be a sequence of variable length chunks of data called records. 
Each record begins with a 2-byte ID data byte followed by 4 bytes define the length of the remainder of the record. 
The last record of a file is an EOF record. 

Multiple-byte data is in little-endian form, i.e., the least significant byte comes first. This is the natural byte order 
40 tor little-endian machines like those based on the Intel 8088 architecture and its descendants. Implementation of the 
form system on big-endian machines, like those based on the Motorola 68000 and its offspring, require a byte swap 
on all multiple-byte data. 

Character data and numeric data are in ASCII format 

The only record that contains environment specific information is the FORMPICTURE record. Because an imple- 
45 mentation can ignore records with a u2PictureFormat that it does not recognize, picture definitions for multiple envi- 
ronments can coexist, i.e., a file can contain both a Macintosh and a MS Windows version of a picture and as a result 
be run on either system. 

Data Element Naming 

50 

In the specification that follows, the name of each data element implies its format on disk. For example, the name 
u2DummyData, based on its prefix (u2), Is a 2 byte unsigned integer with the least significant byte first. Other prefixes 
are defined in Table 1: Name Prefix Definitions. If a name has no prefix (has in initial capital) it is a complex structure 
or sequence defined elsewhere. 

55 
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Table 1: Name Prefix Definitions 



££££lZ Meaning 

1 byte unsigned integer 
u2 2 byte little endian unsigned integer 

u4 4 byte little endian unsigned integer 

sv variable length string (u2 length of 

string followed by string w/o null termination) 
dv variable length data (see separate 

definition) 

ov variable length object code (see 

separate definition) 



General Data File Format 

Every record is organized as shown in Table 2 : 
Record Organization. In the description of individual records 
the 6 header bytes will not be shown. 

Table 2: Record Organization 



Name 

u2RecordType 

u4 RecordLength 

<data portion of record> 



Comments 



length of data portion 



Order of Records 

Records of a graphical image data file will always be in the 
following order; although, some of the records may not be 
present* 

BOF 

IGNORE_REMOTE 
FORMNAMES 
FIELDNAMES 
FONTNAMES 
for each form 
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10 



FORMSIZE 

for each field, text, picture, or pattern 
FORMFIELD, FORMTEXT, FORMPICTURE, or 
FORMPATTERN 
for each field 

FIELDTREE 
FIELDHELP 
FIELDEXPECT 
FIELDVALUE 
for each dBase link 

DBASE_LINK 
for each DDE link 
20 DDE_LINK 
for each ASCII link 
ASCII__LINK 

EOF 



75 



25 



30 



35 



40 



45 



50 



55 



Record Definitions 

EOF record - beginning of file (type = 1) 

liaos Comments 

u2 Appl icat ionid OxA4 19 

u2 Vers ion currently 

Description 

The EOF must be the first record in every 
graphical image data file, Borland International 
may change this number in the future, as the 
D'BlFF is expanded for future needs. 

IGNORE_REMOTE record - ignore remote recjuests (type = 2) 

Hai&fi Comments 
ulIgnoreRemoteRequests i » ignore remote requests 

0 = don't 

Description 

Flag that causes the application to ignore remote 
(DDE) requests for data. 
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FORMNAMES record - form names (type =» 3) 
Name Comments 
u2NumberOf Forms number of names that follow 

svFormName 

• • ■ 
Description 

A form's position in this list of names is its ID, 
beginning at 1, for use elsewhere in this file- 

FIELDNAMES record - field names (type - 4) 
Name g91IBffi?nta 
u2NumberOfFields number of names that follow 

svFieldName 

• • • 
Description 

A field's position in this list of names is its 
ID, beginning at 1, for use elsewhere in this 
file. 

FONTNAMES record - font names (type - 5) 
Name CgTMB^ntg 
u2NumberOfFonts number of fonts that 

svFontName follow the number of u2FontSizethe 

font size in points. 

ulAttributeMask see Table 3 



Table 3: Meaning of ulAttributeMask 

Bits Mask Meaning 

7_3 0XF8 Reserved (must be zero) 

2 0x04 FONT_UMDERLINE 

1 0X02 FONT-ITALIC 

0 0X01 FONT_BOLD 

Description 

A font's position in this list is its ID, 
beginning at l, for use elsewhere in this file 
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FORMSIZE record - form size (type » 6) 

Haas Comments 

u2FormId established in FORMNAMES 

u2xSi2e units: 1/4 of character width 

u2ySize units: 1/8 of character height 
Description 

Size of a form. 



FORMFIELD record - field on a form (type 



7) 



Name 

u2FieldId 

u2xLoc 

u2yLoc 

u2xSize 

u2ySize 

PropertyList 

• • • 
Description 

Definition of 



established in FIELDNAMES 
units: 1/4 of character width 
units: 1/8 of character height 
units: 1/4 of character width 
units: 1/8 of character height 
last property is always 
EOP 

a field item on the form identified 



in the last FORMSIZE record. 



FORMTEXT record 
Name 
svText 
u2xLoc 
u2yLoc 
u2xSize. 
u2ySlze 
PropertyList 



text on a form (type » 8) 
ASCII text 

units: 1/4 of character width 
units: 1/8 of character height 
units: 1/4 of character width 
units: 1/8 of character height 
last property is always EOP 



Description 

Definition of a text item on the form identified 
in the last FORMSIZE record. 
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FORMPICTURE record - picture on a form (type = 9) 
Name Coininents 

u2xLoc units: 1/4 of character width 

u2yLoc units: 1/8 of character height 

u2xSi2e units: 1/4 of character width 

u2ySize units: 1/8 of character height 

PictureDef inition one or more of the following 

u2PictureFormat 0x01 • MS Windows BitMap file 
u4Length number of bytes that follow 

svFileName file containing picture 

u2PictureForinat 0x02 = MS Windows Metafile 
u4Length number of bytes that follow 

svFileName file containing picture 

u2MapMode 

u2PictureFormat otherwise ■ ignore this record 
u4 Length number of bytes that follow 

<bytes to skip> 

u2PictureFormat 0x00 = end of picture formats 
PropertyList last property is always EOP 

• • • 
Description 

Definition of a picture item on the form 
identified in the last FORHSIZE record. Each 
implementation should pick the first picture 
format it recognizes. 

FORHPATTERN record - pattern on a form (type = 10) 

Hana CQwmffltg 

u2xLoc units: 1/4 of character width 

u2yLoc units: 1/8 of character height 

u2xSi2e units: 1/4 of character width 

u2ySize units: 1/8 of character height 

ulPattern 0 = horizontal lines 

1 ~ vertical lines 

2 = diagonal lines, top-left 
to lower-right 
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3 = diagonal lines, lower- 
left to topTight 

4 - horizontal and vertical 
lines (cross) 

5 - diagonal lines in both 
directions (diagonal cross) 
6-0% black (white) 

7 » 6% black 

8 » 13% black 

9 - 19% black 

10 « 25% black 

11 - 50% black 

12 » 75% black 

13 - 100% black 

last property is always EOP 



PropertyList 



Description 



Definition of a pattern item on the form 
identified in the last FORMSIZE record. 



FIELDTREE record - decision tree for a field (type = 11) 



u2FieldId established in FIELDNAMES 

Tree one or more of the following 

(End of tree being last) 



ulNodeDef Branch node (see Table 4) 

ovCondition 

u2FieldId established in FIELDNAMES 

ulNodeOef Conclusion node (see Table 4) 

ovCondition 



ovConclusion 



UlNodeDef 



Null node (see Table 4) 



ovCondition 



UlNodeDef 



End of tree (see Table 4) 
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Table 4: Meaning of ulNodeDef 
HasK Meaning 
7 0x80 flag: node has a sibling 

6 0x4 0 flag: node has children 

5-4 0x30 Reserved (must be zero) 

3-0 OxOF Node type: 0 = End of tree 

1 = Branch 

2 = Conclusion 

3 = Null 

Description 

The decision tree for a field. The best way to 
describe the order of the nodes in the file is to 
show metacode for writing them. To. save a tree to 
disk just pass the top node of the tree to 
SaveNode ( } . 

function SaveNode ( Node ) 

if ( Node ) 

{ 

SaveNode ( Node.FirstChild ) 
SaveNode ( Node.NextSibling ) 
WriteNodeToFile( Node ) 

} 

FIELDHELP record - field specific help (type = 12) 
Name Comments 
u2FieldId established in FIELDNAMES 

svHelpText ASCII help text 

Description 

Help text for a field 

FIELDEXPECT record - field expect (type 18) 
Name Comments 
u2FieldId established in FIELDNAMES 

u2NumberOf Values number of values that follow 

dvValue 
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Description 

This is the list of expected values to be used in 
a list-box or check-box prompt for the field. The 
order of the values is maintained. . 



FIELDVALUE record 
Name 

u2FieldId 
ulValueSource 



field value (type » 13) 
CoTtjments 
established in FIELDNAMES 
0 » User (user input or 
override) 

1 » circular (user input for 

circular tree) 

2 « Link (external link) 

3 » Tree (decision tree) 
dvValue 



Description 



Value for a field. 



DBASE LINK record - dbase link (type » 19) 



mm, 

svLinkName 

svDbaseName 

ullnexact 

u2NumberOf Triplets 



svDbaseFieldName 
u2ReadFieldId 
u2WriteFieldId 



Comments 
Name for link 
File name for dBase file 

0 » Exact 

1 » Inexact 

number of triplets that follow 
Field name 

established in FIELDNAMES 
established in FIELDNAME 



svlndex File name of index file 

Description 

This record defines one dBase link. 
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PDOX_LINK record - Paradox link (type =20) 
HaiBS C<?i(m?nt3 
svLinkName Name of link 

svTabName File name of Paradox table 

ulClosest 0 s Not closest 

1 - Closest 

u2NumberOf Triplets number of triplets that follow 

svTableFieldName Field name 
u2ReadFieldId established in FIELDNAMES 

u2WriteFieldId established in FIELDNAMES 

• • * 

svlndex Name for secondary index field 

Description 

This record defines one Paradox link. 
DDE_LINK record - dde link (type » 15) 

usm Cgfflffigntg 

svServerApp Application name 

svLinkTopic Application name 

u2NumberOf Imports number of pairs that follow 

svRemoteltem Name in remote application 

u2FieldId established in FIELDNAMES 

• « • 

Description 

This record defines one DDE link. 

ASCII_LINK record - ascii link (type -16) 
Name Cgffiffi^ntg 
svFileName File name of ASCII file 

ulAccessType 0 » Read 

1 « Write 

2 Append 

u2NumberOfFieldNames number of names that follow 

u2FieldId established in FIELDNAMES 
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Description 

This record defines one ASCII link. 

5 

EOF record - end of file (type « 17) 
Description 

The EOF record must be the last record in the 
file. It has no data associated with it. 

Property Definitions 

^5 A series of property definitions is a little like a series of records in which the last property definition is the EOP 

property, b) the length of a property is implied by its type instead of being specifically declared, and c) the property 
type is 1 byte long instead of 2. 

NOTITLE property - doni display title (type = 1 ) This property has no data associated with it. 
NOOVERRIDE property - don't allow an overridden (type = 2) This property has no data associated with it. 
20 NOTREESHOW property - don't show tree to user (type = 3) This property has no data associated with it. 

BORDERMASK property (type = 4) 



Names 


Comments 


ulBorderMask 


what borders to display 



Bits 


Mask 


Meaning 


7-4 


OxFO 


Resen/ed (must be zero) 


3 


0x08 


BORDER_BOTTOM 


2 


0x04 


BORDER.TOP 


1 


0x02 


BORDER_RIGHT 


0 


0x01 


BORDER_LEFT 



3S 

The default is to display all borders. 

ALIGNMENT (type « 5) 
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Name 



Comments 



ul Alignment 



tells how to align text 

0 = for left alignment 

1 » for right alignment 

2 = for centered text 

3 = for justified text 



The default is left alignment. 
EOP - end of properties (type - 6) 

This property has no data associated with it. 

FORMAT_GENERAL (type = 7) 

This property has no data associated with it. This property 
is the default format. 



FORMAT_FIXED (type = 8) 
Name 
ulPlaces 



Comments 
decimal places to display 



FORMAT_BUSINESS (type =10) 
Name 
UlPlaces 



decimal places to display 



FORMAT_CURRENCY (type 
Name 
UlPlaces 



= 11) 



Comments 
decimal places to display 



FORMAT_DATE (type =12) 
Name 

ulDateFormat 



mm/dd/yy 

1 = mmmm d, yyyy 

2 « d-mmm-yy 
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3 






A 










HH • Tmn AM / PM 


O 




nnsmiDZSS An/r'n 


7 




hh:inm 


8 




hh:inin:ss 


9 


3 


mm/dd/yy hhrroin 



FOFMAT_LISTBOX (type « 13) 
This property has no data associated with it, 

FORMAT_CHECKBOX (type =14) 
This property has no data associated with it. 



FORMAT_CHECKIF (type = 15) 
This property has no data associated with it. 

FORMAT_BUTTON (type = 16) 
This property has no data associated with it. 



FONT (type = 17) 
Name CgBBBgntg 
u2FontId established in FONTNAMES 

FORMAT_SCROLLING (type - 18) 
This property has no data associated with it. 



FORMAT_PICTURE (type « 19) 
svPictureString Picture definition string 



Variable Length Data 

Data is a type byte followed by a variable-length value. Logical and error values are 1 byte long. Text and numeric 
values are in "sv" fomnat. 

More specifically, a data object Is one of the following: 



Name 


Comments 


ulDataType 
svNumber 


OxlA = number 
the number in ASCII 
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Name 


Comments 


ulDataType 
svText 


Ox1B = text 
the string 



Name 


Comments 


UlDataType 
ulLogicalVatue 


OxIC = logical 

0 = No (false) 

1 = Yes (true) 
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Name 


Comments 


UlDataType 


Ox1d = error 


ulErrorValue 


1 = #DIV/0! (obsolete) 




2 = #Ref ! (obsolete) 




2 = #Valuel (obsolete) 




4 = NA 




5 = #NAME? 




(obsolete) 




6 = #NUM! (obsolete) 




7 = #NULL! (obsolete) 




8 = ERR 



Object Code (Conclusions and Conditions) 

Object code is a sequence of tokens in Reverse Polish order. Some tokens, such as OP_PLUS, are one-bytes 
tokens; some, such as OPERAND_NAME, have fixed-length information that follows; others, such as 
OPERAND_TEXT, are followed by variable length data. The data tokens are the same as data objects defined in the 
section Variable Length Data. Function ID's are listed in Table 5; Function ID's. Here are the details: 



35 



40 



45 



SO 



Name 


Comments 


u2GodeLength 


number of bytes that follow one or more of the 


Code 




following In Reverse Polish 




ulTokenType 


OX01 = OP_NEGATION 




0x02 = OP_PERCENT 




OX03 = OP.EXPONENTIATION 




Ox04 = OP_f^ULTIPLY 




0x05 = OP_DI VIDE 




0x06 = OP.PLUS 




Ox07 = OP_MINUS 




0x08 = OP_AMPERSAND 




0x09 = OP_EQUAL 




OxOA = OP_LESS 




OxOB = OP_GREATER 




OxOC = OP_LESSEQUAL 




OxOD = OP_GREATEREQUAL 




OxOE = OP_NOTEQUAL 




OxOF = OP_POSITIVE 




Ox14 = CONTROL_EQUAL 
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(continued) 


NsnriB 


iMruirirricnis 




Ox15 = CONTROL_PARENS 




Ox16 = CONTR0L_END_OF_LINE_ 


ulTokenType 


0x17 = CONTROL_FUNCTION 


Utroncxioniu 


irom Table 5 


u1 ArgumentCount 


number of arguments 


UlTokenType 


Ox18 = OPERAND_NAME 


u2Fieldla 


established in 


rltLUtNAIvltb 




UlTokenType 


Ox19 = OPERAND_REFERENCE 


u^rieiuia 


established in FIELDNAMES 


avLjaid 


Ox1 A = OPERAND_NUMBER 




Ox1 B = OPERAND_TEXT 




Ox1 C - OPERAND_LOGICAL 








Data) 
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Table 5: Function ID's 

112 Function 

0x01 §INT 

0x02 eOATE 

0X03 eOATEVALUE 

0x04 eOAY 

0X05 eHOUR 

0X06 eMINUTE 

0x07 §M0NTH 

0X08 §NOW 

0X09 eSECOND 

OXOA eTINE 

OXOB QTIHEVALUE 

OXOC eWEEKDAY 

OXOD eVEAR 

OXOE eROUNO 

OXOF §TYPE 

0x10 §SUM 

0X11 ©MAX 

0X12 §MIN 
0X22 eCHAR 
OX23 §CODE 
0X24 §EXACT 
0X25 ©FIND 
0X26 §LEFT 
0X27 ©LENGTH 
0X28 eMID 
0x29 ©REPLACE 
0x30 ©REPEAT 
OX31 ©RIGHT 
0X2 C ©ABS 
OX2D ©MOD 
0X2 E ©AND 
0X2F ©IF 
0x30 ©NOT 
Ox31 ©OR 
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0X32 


eUPPER 


0X33 


§L0WER 


0x34 


emjLL 


0X35 


§MESSAGE 


0x36 


§ERR 


0X37 


SNA 


0x38 


ePXOPEN 


0x39 


eCLOSE 


Ox3A 


#TOP 


0X3 B 


§BOTTOM 


0X3 C 


iPREVIOUS 


0X3 D 


§NEXT 


0x3 £ 


§CLEAR 


Ox3F 


SDELETE 


0x40 


UPDATE 


0X41 


INSERT 


0X42 


e STORE 


0x43 


iASCIIOPEN 


0x44 


§DDEOPEN 



Limits Imposed by this Format 

This file definition constrains you to 



OBJECT 


LIMIT 


Forms 


65,535 


Fields 


65,535 


Fonts 


65,535 


Font size 


65,535 


Nodes in a tree 


65,535 


X position 


16,383 characters 


Y position 


8,191 characters 



Properties Matched to Item Type 


Property 


Field 


Text 


Picture 


Pattern 


NOTITLE 


X 








NOOVERRIDE 


X 








NOTREESHOW 


X 








BORDERMASK 


X 


X 


X 


X 


ALIGNMENT 


X 


X 






FORMAT.GENERAL 


X 








FORMAT.FIXED 


X 








FORMAT_PERCENT 


X 
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(continued) 



Properties Matclied to Item Type 



Property Field Text 



Picture 



Pattern 



FORMAT_BUSINESS X 

FORMAT_CURRENCY X 

FORMAT_DATE X 

FORAMT.LISTBOX X 

FORMAT_CHECKBOX X 

FORMAT_CHECKIF X 

FORMAT_BUTTON X 

FORMAT_SCROLLING X 

FORMAT.PICTURE X 



FONT X X 

EOP X X 



X 



X 



X= Has nneaning 



. = Has no meaning (and is ignored) 



APPENDIX B 

APPLICATION PROGRAM OPENING WINDOW (Fig. 5) 

File . New - close any open application and prepare for a new application; 

Open - open an application from a list of applications currently on the disk; 

Resume - resume goal orienting prompting in the goal form after an interruption; 

Save - save to the file of the current name; 

Save As - Save as a new named file; 

Print Form - prints the current form and contents; 

Print All - prints all of the forms of a stack; 

Exit - return to WINDOWS; 

About - display information about form system; 

Edit Undo - undo the last change; 

Cut - cut a designated entity and save on clipboard for subsequent use; 

Copy - copy a designated entity to a clipboard for subsequent use by the paste command; 

Paste - paste an entity from a clipboard to a designated location; 

Clear All - clear data from all forms of a stack; 

Form Select - displays a list of forms for selection; 

Clear - clears data from the current form only; 

Field Find - prompts for name of field to be found; 
Calculate - requests calculation of the field; 
Show tree - displays the tree for the field; 

View Screen - presents display in screen format; 

Printer- presents display in the printer format; 

Tools Form - select Form tool and select Form Tool Operations from Menu-Items shown in Fig. 6; 
Tree - select Tree tool and select Tree Tool Operations from Menu-Items shown in Fig. 7; 
Stack - select Stack tool and select Stack Tool Operations from Menu-Items shown in Fig. 8; 
Link - follow dialogue windows to create and/or edit links; 
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FORM TOOL WINDOW OPERATIONS (FIG. 6) 



TO 



15 



20 



25 



30 



Form New - Close any open form & prepare for ne form; 

Select - Select a form from list of forms; 
Find - Find a form with a defined field name; 
Close Tool - Close the form tool & return to completion mode; 

Edit Undo - undo the last change; 

Cut - cut a designated entity and save on clipboard for subsequent use by paste command; 
Copy - copy a designated entity to a clipboard for subsequent use by the paste command; 
Paste - paste an entity from a clipboard to a designated location; 

Obiects Field - Create a field object, place the field on the form, & set the size of the field; 

Text - Create a text object, place the object on the form, & set the size of the object; 
Fill Rect - Select a filled rectangle object, place the object on the form, select a hatch pattern, and 
set the size of the object; 

Rounded Rectangle - Select a rounded rectangle object, place the object on the form, select a hatch 
pattern, and set the size of the object; 
Line - Select a line object and place the line on the form; 

Graphic • Create a graphic object, place the object on the form, specify the graphic image, and set 
the size of the object; 

Properties Repeat - Repeat the last selected property; 
Field Type 

General - text and numerical; 
Fixed - numerical with set decimal places; 
Percent - numerical only with % display; 
Financial - numerical with comma separators; 
Currency - numerical with currency symbols; 

Date/Time - serial number of date and time since January 1 , 1900 - displays date & time; 
Scrolling - scroll through field; 

True/ False - For field values Yes or No; the field is displayed with YES and NO check boxes; 
Button - For fields which default to NO but can be momentarily set to YES; 

Picture - define permitted format of entry; 

Selection List - For fields with one of several values from a list which is not displayed in the field; 
Check Box - For fields with one of several values which are displayed as check boxes in the field; 
If the field display size is too small to accommodate the boxes, a selection list is displayed when 
the field is prompted; 

Alignment Left - Left alignment is the default for newly created fields; field values and text objects are displayed 
at the left edge of the object's display area; 
Right - field values and text objects are displayed at the right edge of the object's display area; 
Center - field values and text objects are centered in the object's display area; 
Justified - Aligns mu Iti-line field values and text objects flush against the object's left and right margins; 

Font Select a font type and font size from a list; 

Borders Outline - This is the default for newly created fields and places lines on all sides of field; 

Left - Places vertical line at left edge of object; 
Right - Places vertical line at right edge of object; 

Top - Places horizontal line at top edge of object; Bottom - Places horizontal line at bottom edge of 
object; 

Fill Pattern Select a different fill pattern for a selected filled rectangle or a rounded rectangle; 
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Line Width 



Select a different line width for object borders or for lines; 



Protection No override - User cannot enter value in a calculated field; 
No tree display - Tree is not displayed; 

Field Replace the selected field object with a new field object; 

Name/Text Edit field nanne; 

Help Attach Help to selected field; 

View Screen - displays screen view; 

Printer - displays forms as they will appear when printed; 

Tools Tree - Selects Tree tool; 

Stack - Selects Stack tool; 
Link - Selects Link tool; 



TREE TOOL WINDOW OPERATIONS (FIG. 7) 

Tree Select - Select a tree from a list of trees; 

Find - Find a tree containing an identified field in a branch, condition, or conclusion; Print - print 

current tree; 

Print all - print all trees; 

Close tool - close the Tree tool; 

Edit Undo - undo the last change; 

Cut - cut a designated entity and save on clipboard for subsequent use by paste command; 
Copy - copy a designated entity to a clipboard for subsequent use by the paste command; 
Paste - paste an entity from a clipboard to a designated location; 

Obiects Branch - Insert a branch object at the same level as the highlighted object (in parallel); 
Conclusion - Insert a conclusion at the same level as the highlighted object; 

Properties Field - Use a new field or another existing field to replace the field in the current branch object; 
Condition - Change the condition that selects the current object; 
Conclusion - For conclusion object-edit expression; 
Name - For branch object - edit name; 

View Expand - Expand display; 

Reduce - Reduce display; 

STACK TOOL WINDOW OPERATIONS (FIG. 8) 

Stack Close tool - Close the stack tool; 

Edit Undo - undo the last change; 

Cut - cut a designated entity and save on clipboard for subsequent use by paste comment; 
Copy - copy a designated entity to a clipboard for subsequent use by the paste command; 
Paste - paste an entity from a clipboard to a designated location in the stack; 
Clear All - clear data from all forms of a stack; 

Obiects Fomn - Add a new form to the stack; 

Properties Title - Edit the title of the highlighted form. 
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Claims 

1. A programmable controlled, goal oriented electronic system for torm creation and form completion comprising: 

means for generating and nrieans for using form data files which define: 

a graphical image (13,14,16,18,19,20) of at least one goal oriented form for display on a monitor; 
a graphical image (15,24.25,26.30,31,32) of at least one decision tree discretely associated with fields of a 
form, wherein said at least one decision tree specifies operations to be performed by the system in order to 
complete a field of said at least one goal oriented form. 

2. A system in accordance with claim 1 wherein: 



each said decision tree comprises branch objects (24) and conclusion objects (25); and wherein 
said objects define logical relations and/or mathematical operations which are the basis for goal oriented 
'5 prompting within a form and among forms of a set of forms as defined in said form data files. 

3. A system in accordance with claim 1 wherein: 

said system for generating form data files further comprises: 

means for selectively defining data links between selected fields of one or more f omns and a variety of different 
20 data sources/destinations. 

4. A system in accordance with claim 3 wherein: 

said data links are selectively defined as being reading and/or writing links. 

2S 5. A system in accordance with claim 3 wherein: 

said variety of data sources/destinations include: a file of a relational data base; and an ASCII data file. 

6. A system in accordance with claim 3 wherein: 

said variety of data sources/destinations includes a dynamic data exchange link (DDE) to an application 
30 program. 

7. A system in accordance with claim 3 wherein: 

said system comprises means for detecting a request for a link to a non-existent data source/destination; 
and means for creating a data base in which the fields correspond in name and characteristics to the fields named 
35 In said link request. 

8. A system in accordance with claim 1 wherein: 

said means for generating comprises a form tool and a tree tool. 

40 9. A system in accordance with claim 3 wherein: 

said means for defining data links comprises a link tool. 

10. A system in accordance with claim 1 wherein: 

said system comprises a fonm creation mode of operation for generating and using said graphical images; 
45 and a run time mode of operation with facilities limited to use, but not alteration, of said form data files. 

11. A system in accordance with claim 9 wherein: 

said run time mode of operation comprises means for selecting a field of a form; and means for selectively 
displaying a decision tree assigned to that field. 

50 

Patentanspruche 

1 . Programmgesteuertes, zielorlentiertes, elektronisches System zum Erzeugen und Vervollstandigen von Formblat- 
55 tern, umfassend: 

eine Einrichtung zum Erzeugen und eine Einrichtung zum Verwenden von Formblatt-Datendateien, welche defi- 
nieren: 
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ein graphisches Bild (13, 14, 16, 18, 19, 20) von wenigstens einem zielorientierten Formblatt zum Anzeigen 
an einem Monitor; 

ein grapliisches Bild (15, 24, 25, 26. 30, 31 , 32) wenigstens eines den Feldern eines Formblatts diskret zu- 
geordneten Entscheidungsbaums, wobei der wenigstens eine Entsclieidungsbaunn die Operationen inn ein- 
s zelnen angibt, welche durch das System ausgefuhrt werden, um ein Feld des wenigstens einen zielorientierten 

Formblattes zu vervollstandigen. 

2. Systenn gemaB Anspruch 1, 

10 bei welchem jeder der Entscheidungsbaums Abzweigobjekte (24) und Folgerungsobjekte (25) umfaBt; und 

wobei die Objekte logische Beziehungen und/oder mathematische Operationen deflnieren, welche Innerhalb 
eines Formblatts und zwischen Formblattern eines Satzes von Formblattem, wie sie in den Formblatt-Daten- 
dateien festgelegt sind, die Grundlage fur eine zielorientierte Bedienerfuhrung sind. 

IS 3. Systenn gemaB Anspruch 1 , 

wobei das System zum Erzeugen von Formblatt-Datendateien ferner umfaBt; 

eine Einrichtung zum selektiven Festlegen von Datenverknupfungen zwischen ausgewahlten Feldern eines Oder 
mehrerer Formblatter und einer Vielzahl von verschiedenen Datenquellen/Datenzlelen. 

20 4, Systenn gemaB Anspruch 3, 

wobei die Datenverknupfungen selektiv als Leseverknupfungen und/oder als Schreibverknupfungen festgelegt 
sind. 

5. System gemaB Anspruch 3, 

25 wobei die Vielzahl von Datenquellen/Datenzielen enthalten: 

eine Datei einer relationalen Datenbank; und eine ASCII-Datendatei. 

6. System gemaB Anspruch 3, 

wobei die Vielzahl von Datenquellen/Datenzielen eine dynamische Datenaustauschverknupfung (Dynamic Data 
30 Exchange Link, DDE) an ein Anwendungsprogramm enthalten. 

7. System gemaB Anspruch 3, 

wobei das System eine Einrichtung zum Erfassen einer Anforderung fur eine Verknupfung mit einer nicht 
35 vorhandenen Datenquelle/einem nicht vorhandenen Datenziel umfaBt; und 

eine Einrichtung zum Erzeugen einer Datenbank, in welcherdie Felder bezuglich des Namens und den Kenn- 
daten den in der Verknupfungsanforderung benannten Feldern entsprechen. 

8. System gemaB Anspruch 1 , 

40 wobei die Einrichtung zum Erzeugen ein Formblatt we rkzeug und ein Baumwerkzeug umfaBt. 

9. System gemaB Anspruch 3, 

wobei die Einrichtung zum Festlegen der Datenverknupfungen ein Verknupfungs-Werkzeug umfaBt. 

45 10. System gemaB Anspruch 1, 

wobei das System eine Formblatt-Erzeugungsbetriebsart zum Erzeugen und Verwenden der graphischen 
Bilder umfaBt; und 

eine Laufzeit-Betriebsart umfaBt, welche auf das Verwenden beschrankt aber nicht fur das Andem der Form- 
50 blattdaten-Dateien Unterstutzung bietet. 

11. System gemaB Anspruch 9, 

wobei die Laufzeit-Betriebsart eine Einrichtung zum Auswahien eines Feldes eines Formblatts umfaBt; und 
55 eine Einrichtung zum selektiven Anzeigen eines Entscheidungsbaums, welcher diesem Feld zugewiesen ist. 
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Revendications 

1. Systfeme 6lectroniquecommand§ programmable, d6d!66 !acr6ation etau remplissagedetormulaires, comportant: 

des moyens pour g^n^rer et des moyens pour utiliser des fichiers de donn6es de tormutaires qui d6finissent : 

une image graphique (13, 14. 16, 18, 19, 20), d'au moins un formulaire d6di6. k afficher sur un moniteur; 
une image graphique (15, 24, 25, 26, 30, 31 , 32) d'au moins un arbre de decision assocl6 individuellement k 
des champs d'un tormulaire, dans lequel ledit arbre de d6cislon au nombre d'au moins un sp6cifie des op6- 
rations k ex6cuter par le systdme afin de remplir un champ dudit formulaire d6di6, au nombre d'au moins un. 

2. Syst^me selon la revendication 1 , dans lequel : 

chaque dit arbre de d6cision comporte des objets de branchement (24) et des objets de conclusion (25) ; et 
dans lequel 

lesdits objets d§finissent des relations logiques et/ou des operations math^matiques qui constituent la base 
d'un guidage d6di6 k I'intdrieur d'un lormuiaire et parmi des formulaires d'un ensemble de formulaires, tel que 
d^fini dans lesdits fichiers de donn^es de formulaires. 

3. Syst6me selon la revendication 1 , dans lequel : 

ledit systdme pour g6n§rer des fichiers de donn6es de formulaires comporte, en outre : 
des moyens pour d^finir s6lectivement des liens de donn6es entre des champs s6lectionn6s d'un ou de 
plusieurs formulaires et un 6ventail de diff6rentes sources / destinations de donn^es. 

4. Syst^me selon la revendication 3, dans lequel : 

lesdits liens de donnees sont d6finis s6lectivement comme liens de lecture et/ou d'^criture. 

5. Syst^me selon la revendication 3, dans lequel : 

ledit 6ventail de sources / destinations de donn6es comprend : un fichter d'une base de donn§es 
reiationnelle ; et un fichier de donn6es ASCII. 

6. Syst^me selon la revendication 3, dans lequel : 

ledit 6ventail de sources / destinations de donnees comprend un lien d'6change dynamique de donnees 
(DDE) avec un programme d'applications. 

7. Systeme selon la revendication 3, dans lequel ledit syst6me comprend des moyens pour d^tecter une demande 
d'un lien avec une source / destination de donnees inexistante ; et des moyens pour cr6er une base de donnees 
dans laquelle les champs correspondent en nom et en caract6ristlques aux champs nommes dans ladite demande 
de lien. 

8. Systeme selon la revendication 1 , dans lequel : 

lesdits moyens de g6n6ration comportent un outil pour formulaires et un outil pour arbres. 

9. Systeme selon la revendication 3, dans lequel : 

lesdits moyens de definition de liens de donn6es comportent un outil pour liens. 

10. Systdme selon la revendication 1, dans lequel : 

ledit systeme comporte un mode de fonctionnement en creation de formulaires pour g6nerer et utiliser les- 
dites images graph iques ; et un mode de fonctionnement en execution ayant des posslbilites limitees k Tutilisation, 
mais n'autorisant pas la modification, desdits fichiers de donn6es de formulaires . 

11. Systeme selon la revendication 9, dans lequel : 

ledit mode de fonctionnement en execution comporte des moyens pour s6iectionner un champ d'un formu- 
laire; et des moyens pour afficher s^lectivement un arbre de decision atfecte audit champ. 
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APPUCATION PROGRAM 



FORM TOOL (FORM CREATION) 



TREE TOOL (FORM CREATION) 



LINK TOOL (FORM CREATION) 



STACK TOOL (FORM CREATION) 



MEMORY MANAGER 



FORM EXECUTION (RUN TIME) 



TREE EXECUTION (RUN TIME) 



LINK MANAGER 



FILE 1-0 SUBSYSTEM 



WINDOWS INTERFACE 



Fig. 3 



301 
302 

303 
304 

.305 

. 306 
^ 307 
_^308 

^309 

.310 



FORM IMAGE DATA FILE 



BOF 

IGNORE REMOTE 
FORMNAMES 
FIELDNAMES 
FONTNAMES 

For •ach Form 
FORMSIZE 

400 For each Form obltet 

FORMFIELD.FORMTEXT, 
FORMPICTURE. or FORMPATTERN 

For each ff«id 
FIELD TREE 
FIELOHELP 
FIELDEXPECT 
FIELD VALUE 

For each link 

DBASE^LINK 
DDE_LINK 
ASCILLINK 



EOF 



Fig. 4 
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Form System - (Tlile) 
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New 
Open 
Resume 
Save 
Save As 
Print Form 
Print All 
Exit 
About 



Undo 

Cut 

Copy 

Paste 

Clear 



All 



n 

Select 
Clear 



Find Screen Form 

Calculate Printer Tree 
Show Tree Stack 

Links 



Control Button 

Restore 

Move 

Size 

Minimize 
Maximize 
Close 
Switch to 
Ru n 

EingirrgMri 



Fig. 







Form System - (Title) 
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New Undo Field Repeat Screen Tree 
Select Cut Text Field Type Printer Stack 
Find Copy fih Rect Alignment Link 
Close Paste Grophic Label Font 

Borders 

Protection 

Field 

Nome/Text 
Help 
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